When a spacecraft, such as a communications satellite, is built it has both processing and non-processing aspects. The non-processing aspects include the structural, power, and thermal subsystems. The processing aspect includes all of the subsystems that process or generate data or control parts of the spacecraft. Typically, each subsystem will address a specific functional area, such as guidance, communications, and data handling. This decomposition allows each subsystem to be developed with relative independence and to operate independently. A common hardware architecture for such a system will use a system data communication bus, which interconnects all of the subsystems.
More so than other hardware system, spacecraft design is driven by several factors other than the operational functionality of the system. These factors include size, weight, power use, and heat generation in addition to the ability to resist environmental conditions such as radiation, vibration, and temperature. Size, weight, power and heat considerations typically drive the design to minimize the number of components in any system or subsystem.
In a traditional development, each of the subsystems will design and implement its own interface, or connection, to the system bus. This interface will be unique to each subsystem, implementing the exact set of capabilities needed by that subsystem. The interface will differ from subsystem to subsystem within the same system. It will also vary between different implementations of the same subsystem across different systems. This variation in design is driven both by the needs of the subsystem and the need to minimize the size, weight, etc. by minimizing the number of components.
Common, reusable designs have not been developed since each subsystem will need a different set of capabilities, such as serial communication, parallel communication, etc. A universal solution which meets all possible needs would include extraneous components, unused by the subsystem, which contribute to the parts count and negatively impact the design factors.
Often, the system bus interface will be implemented as a printed circuit board (PCB) using standard components that are qualified for the environmental conditions. This would require approximately 20 LSI and MSI integrated circuits, plus discrete components, and would occupy up to 160 square inches of printed circuit board area.
While the technology is available to implement the interface as a single integrated circuit, such as an application specific integrated circuit (ASIC), this is not usually economically viable. The very small number of each version is insufficient to offset the fixed startup costs required to begin production.
The PCB approach incurs several costs relative to the ASIC solution. It is larger; weighs more; has a higher parts count; and consumes more power. Further, because each is a new design and implementation, time and costs to design, fabricate, and test must be paid for each new interface.
Attempts have been made to develop ASICs that are applicable to range of common subsystems. Chip sets are available which implement the common data protocols, such as MIL-STD-1553. However, such ASICs usually do not include a processor for a variety of reasons. These include: inability to achieve the required component density in a radiation hardened configuration; software debug techniques, such as in-circuit emulation, could not be used with ASIC embedded processors; and the cost of developing a new processor design for use in an ASIC was prohibitive.
There is a need for an ASIC implementation of an interface to a system bus that is sufficiently flexible that it can be used in a variety of subsystem applications. With enough re-use, sufficient quantity can be produced to bring the price per part down to a viable level. Ideally, such an ASIC would replace the PCB currently used with a single chip, resulting in significant size, weight, power use, and heat generation savings. Additional benefits could be realized reducing design time and increasing reliability. These would result from not having to re-design and re-test the interface for each implementation.